home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 639 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.5 KB
  1. From: itschere@techfak.uni-bielefeld.de
  2. Subject: Re: XATTR structure for biosfs entries
  3. Date: Wed, 10 Nov 93 15:59:38 MET
  4. In-Reply-To: <9311101240.AA16548@math.uni-muenster.de>; from "Ulrich Kuehn" at Nov 10, 93 01:40:20 pm
  5.  
  6. Hi Ulrich,
  7.  
  8. > |> Ah, yes, this one doesn't sound bad :-) but just at this moment a more
  9. > |> general problems comes to my mind: If the device driver has full access
  10. > |> to its XATTR field, it can also change its own uid/gid or so. This won't
  11. > |> matter for the built-in ones, but someone _could_ write a driver which
  12. > |> can self-change its uid to superuser... Looks a bit like a security hole :-(
  13. > |>
  14. >
  15. > Well, if you can put your own device driver into the system folder, then
  16. > THAT is a security hole, as a device driver can (in priciple) do anything
  17. > it wants, even change the uid of the current process, and it does not need
  18. > access to its own file uid/gid field. I think this is definitly not a
  19. > security hole.
  20.  
  21. Well you mustn't put an XDD driver into the system folder, you can also
  22. start it up using "normal" dcntl's and come to the same problem... :-(
  23.  
  24. The longer I think about this, the more my head begins to hurt...
  25.  
  26. So, to make it really secure, it looks like Dcntl's on the biosfs should
  27. be limited to superuser processes.
  28.  
  29. bye,
  30. TeSche
  31. -- 
  32. PS: If the above written looks weird, than that's because it probably IS.
  33. WhoDunnIt: Torsten Scherer (Schiller, TeSche...)
  34. Technical Faculty, University of Bielefeld, Germany (52'5"N 8'35"E)
  35. EMail: itschere@techfak.uni-bielefeld.de / tesche@dave.hrz.uni-bielefeld.de
  36.